avoid calling FamilyPcgs
#2656
avoid calling FamilyPcgs
#2656
Conversation
(Probably this will not be a complete fix.)
|
I need the relations relative to exactly the generators of the group, getting differnt ones will not be helpful |
|
@fieker Then what about the following: |
|
Will I get the pc relations this way?
…On Fri, 11 Aug 2023, 13:55 Thomas Breuer, ***@***.***> wrote:
@fieker <https://github.com/fieker> Then what about the following:
Oscar.relations(G::PcGroup) checks whether the stored generators actually
are a pcgs. If yes then it calls GAP's IsomorphismFpGroupByPcgs,
otherwise it calls GAP's IsomorphismFpGroupByGenerators.
(In fact, one could then do this in Oscar.relations(G::Oscar.GAPGroup),
and no special method for pc groups is needed.)
—
Reply to this email directly, view it on GitHub
<#2656 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA36CV4LHTMD3FHJEI6T6LLXUYMRTANCNFSM6AAAAAA3MU4SKA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Suppose the given group If the stored generators are a pcgs for |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2656 +/- ##
=======================================
Coverage 71.91% 71.92%
=======================================
Files 429 429
Lines 60812 60812
=======================================
+ Hits 43731 43736 +5
+ Misses 17081 17076 -5
|
(Probably this will not be a complete fix.)
(Probably this will not be a complete fix.)
Calling GAP's
FamilyPcgswith a proper subgroup of a pc group yields a pcgs for the full pc group, see gap-system/gap/issues/5483.If I remember right then the idea of
relations(G)for a groupGwas that the relations hold w.r.t. the generators stored forG, and then the proposed change will in general violate this assumption.Perhaps it would be safer to change
relationssuch that also the list of generators is returned w.r.t. which the relations hold.